OpenEdge Application Server:<br />Developing AppServer Applications Stateless operating mode

Unlike state-reset or state-aware, an AppServer running in stateless operating mode does not dedicate any AppServer agent to a client connection. Instead, all AppServer agents remain generally available to execute remote procedure and user-defined function requests from all connected client applications.

When a client connects to an AppServer that is running in stateless operating mode, the AppServer broker maintains the connection between itself and the client. The AppServer broker can then dispatch each remote procedure request from the client to any available AppServer agent to execute. Because any AppServer agent that executed a previous request from this client might not be available, the AppServer agent that handles subsequent requests might be different.

General AppServer-client interaction

The general interaction between a stateless AppServer and client proceeds as follows:

The client connects to the AppServer broker with or without the help of a NameServer, which provides the address of the broker from a list of AppServers that support a specified application service. The broker is then available to handle application service requests from this client or to accept a connection request from another client.

Note: The algorithm the NameServer uses to choose the broker depends on whether the NameServer is configured for load balancing. For more information, see the "Load balancing and session models" section.

The client invokes an application service request (synchronously or asynchronously).

The connected AppServer broker passes the client request to an available AppServer agent.

The agent executes the request and returns the results to the broker, which returns the results to the client. The AppServer agent is immediately available to handle an application service request from any client connected to the broker.

The client handles the results of the application service request and either invokes another request as in Step 2 or disconnects from the AppServer as in Step 6.

When the client no longer requires the application service, it disconnects from the AppServer broker and cleans up after its connection to the application service.

The number of available simultaneous client connections to a stateless AppServer is limited only by the required performance for each client connection. The performance of client connections depends on the availability of an AppServer agent to execute a client request. Agent availability depends on the:

Resources of the AppServer machine.

The number of agents the AppServer is configured to startup and manage at one time.

The number and types of client requests to the stateless AppServer.

Connection management

By default, all connections on a stateless AppServer are unbound—that is, all AppServer agents are available to handle requests from any client connection. As long as an AppServer agent is not currently handling a client request, it can handle requests from any connected client. However, at any time during the handling of a client request, a client connection can become bound—that is, the AppServer agent handling the request becomes available to handle requests only from the client it is currently servicing. While a connection is bound, all requests from the connected client are handled by the same AppServer agent. In the same way it became bound, at any time during the handling of a client request, a bound connection can become unbound, at which point requests from the connected client can be handled by any available AppServer agent.

In general, then, a stateless AppServer agent is available to handle a client request as long as it is not currently processing a client request and as long as it is not waiting on a bound connection. If a stateless AppServer has no AppServer agents available to handle requests, all requests are queued at the AppServer broker until an AppServer agent becomes available.

To help an AppServer session perform common connection tasks, such as user authentication, you can configure a Connect procedure that runs for each connection request and a Disconnect procedure that runs for each disconnection request. For more information on these procedures, see Chapter 2, " Programming the AppServer."

A connection in the unbound state can transition to the bound state in two ways:

A client application instantiates a remote persistent procedure in the context of the connection. The AppServer agent that handles the remote persistent procedure request thus becomes bound to the connection.

The AppServer agent runs a procedure that sets the SERVER-CONNECTION-BOUND-REQUEST attribute on the SESSION handle to TRUE. The AppServer agent that sets this attributes thus becomes bound in the connection.

Note that it is the successful instantiation of a remote persistent procedure that forces the connection to transition from the unbound state to the bound state. If a client fails in its attempt to instantiate a remote persistent procedure on an unbound connection, the connection remains unbound.

Performance considerations

Because a stateless AppServer passes requests from connected clients to any available AppServer agent, the number of clients that a single AppServer instance can handle using this operating mode is relatively high. That is, a relatively small number of AppServer agents can support many client connections. If you never set connections to the bound state, a stateless AppServer can make maximum use of its available AppServer agent resources to handle client requests. This operating mode thus maximizes throughput for large numbers of clients, especially when they maintain short connections.

Context management

An AppServer running in stateless operating mode does not reset its session context between client connections. Instead, it maintains most all context created in an AppServer session until a particular AppServer agent terminates or the context is changed by some procedure running in the AppServer session.

For an AppServer running in stateless operating mode you can also configure Startup and Shutdown procedures that run in every AppServer session when it starts up and shuts down. You can use these procedures to establish and discard run-time context that the AppServer maintains in common for all connections. For more information on the Startup and Shutdown procedures, see Chapter 2, " Programming the AppServer."

Using a bound connection, the AppServer maintains all session context created between client requests (similar to a state-aware AppServer), because the bound connection maintains one AppServer agent to execute all requests for the same connected client until you reset the connection to the unbound state.

Using an unbound connection, the AppServer does not automatically guarantee that context created during a remote procedure request will be available when the same client makes the next request. As noted in a previous section, this is because a stateless AppServer cannot guarantee that the same AppServer agent will handle the next request. However, you can still maintain context created between requests from a connected client, but only by explicitly saving the created context using one of several mechanisms. Two such mechanisms specially supported for stateless AppServers include:

The SERVER-CONNECTION-CONTEXT attribute on the SESSION handle that allows you to pass CHARACTER data from one request to another on the same client connection.

Activate and Deactivate procedures that you can configure to execute before and after each remote procedure request.

As noted in a previous section, OpenEdge does not automatically delete any AppServer session context between requests to a stateless AppServer. The only exception to this is if a client application disconnects from a stateless AppServer while it has remote persistent procedures active in the AppServer session. In that case, OpenEdge does automatically delete the active remote persistent procedures before disconnecting the client application.